Подписаться
Опубликовано

Оптимизация процесса завершения задачи в команде

Автор
  • Имя
    Счастливый тимлид | ♥ Frontend
    Telegram

У меня кажется закончился процесс адаптации к новому проекту. Пришло время проявлять проактивность. Я начал с больного – нужно улучшать процессы. Решил действовать постепенно и в пятницу предложил небольшие изменения в процессе "завершения работы над задачей", а именно предложил выкинуть все "больные" пункты из процесса:

... 5. Идем на удаленную тачку через rdp 6. Там подключаемся через samba к серверу 7. Открываем гуглдокумент, в котором список тасок и стендов (здесь это называется "прототип") 8. Ищем по дате наиболее старый 9. Кликаем на ссылку с задачей и проверяем, что задача закрыта - значит что стенд свободен. Иначе возвращаемся на пункт 8 10. Запоминаем номер свободного сервера 11. В графе с сервером обновляем дату и ставим ссылку на текущую задачу. 12. Заходим в папку с номером выбранного сервера 13. Делаем git checkout на нашу ветку ...

Теперь должно выглядеть так: ... 4. Коммитим все это дело 14. Идем в Жиру. 15. В ней выбираем связанную ветку - переходим в битбакет 16. Создаем пулл-реквест. ...

А уже тестировщик, когда берет задачу в тест, самостоятельно разворачивает пулл-реквест на нужном стенде и тестирует. А потом и сам мержит, если нет конфликтов.

Кажется это очевидным, и в вашей компании это скорее всего уже так работает, но на моем проекте все привыкли работать как работалось и "спасение утопающих в руках самих утопающих".

Я рад, что лид принял мои замечания и уже сегодня с утра в общем чате объявил об оптимизации процесса. Конечно появились и несогласные, но это нормально. Всегда люди сопротивляются чему-то новому и хорошему, потому что привыкли к старому.

Счастливый тимлид | ♥ Frontend
2204 подписчика
692 поста

Закрепленные

Из подборки #процессы

Свежие посты

Опубликовано

Телеграмовский сосун (или какун, как правильно?)

Телеграмовский сосун суммирует мой лонгрид – стоит ли публиковать полную версию?